That's the good news. The bad news is, it's still affected by CVE-2007-5925, which allows remote authenticated users to cause a denial of service (database crash). J rg Br he wrote on the packagers mailinglist that's because the sources for 5.0.51 were cloned before the fix got in. I don't know exactly how their release model works, but looks like it needs to be improved.

To make it even worse, bug #32125 which has a patch for the problem, was set to private a few days ago. Because we already have the patch in our MySQL packages since exactly three weeks, it's available in our subversion repository.

Scheduled downtime of the backports.org main machine on Friday morning at about 09:00 CET. Please don't drop me mails, or try to reach me on the phone because you think you have to tell me that the machine is down (yes, it already happened in the past), I'm aware of it.

The next upload of the MySQL packages to Debian (both branches, 5.0 in unstable and 5.1 in experimental) will disable binary logging in the default configuration file. I think most users of the MySQL packages in Debian don't really need it, and otherwise (e.g. on a replication master, or for point-in-time recovery) they know how to enable it.

This change only affects you when you're doing a fresh installation of the mysql-server package, or if you're still running the default configuration file shipped with the package. If you modified the configuration file in the past already (which should be the case when using replication, because the server_id line is disabled by default), the change will not be applied during an upgrade without explicit confirmation.

This morning I prepared and uploaded a Debian package of mylvmbackup, which provides a quick way to create backups of MySQL server's data files using an LVM snapshot. While it's waiting in Debians NEW queue for approval by the FTP masters, you can get it from here. It was built on and uploaded to unstable, but the package works fine on stable (etch) as well.

Today I was contacted by MySQL, they wanted to know If I mind when the MySQL category of my personal weblog would be added to Planet MySQL. Of course I didn't mind, so here I am...

For those of you who want to use MySQL 5.1 on etch, I prepared a backport from the experimental package of MySQL 5.1.22-rc. It's available for amd64 and i386, but will not be uploaded to the backports.org archive until there's a stable release in lenny.

Take a look at the list of Open Issues in MySQL 5.1 before upgrading your servers.

Last night I prepared a Debian package of MySQL Proxy. It still lacks an init script and a manpage, but beside that it works fine. I plan to finish and upload the package to unstable within the next days.

For details about using MySQL Proxy read Getting Started with MySQL Proxy by Giuseppe Maxia.

Yesterday I visited the MySQL Customer Conference in Munich. First of all, GDL sucks. But the locomotive driver strike was the only negative issue on that day, the conference itself was quite good, especially Jan Kneschke's talk about MySQL performance tuning (which was mostly about combining MySQL Cluster and MySQL Proxy) and the panel discussion about storage engines with Ralf Gebhardt, Jan Kneschke and Kai Voigt as vocal and Kaj Arn as moderator. All in all a great (but quite long and exhausting) day.

Santiago Vila uploaded base-files 4.0.1~bpo40+1 to backports.org, because the package from etch doesn't include the GPLv3 license. If you're going to upload the backport of a package which software is under the GPLv3, please make sure it depends on at least this version of base-files.

I just uploaded lsof 4.79J to experimental. It's a pre-release with support for file flags and file offsets, and requires the new entries from /proc/N/fdinfo/ which are available since Linux 2.6.22.

Test with: sudo lsof -o grep -e 0t grep -vwe 0t0

While updating the Debian package of xchat-gnome to the latest upstream release, I also wanted to check if the package in Ubuntu includes some patches relevant for Debian. Ubuntu unfortunately doesn't forward small patches relevant for Debian to it's bug tracking system, but provides one big patch on http://patches.ubuntu.com/ instead...

-rw-r--r-- 1 tretkowski tretkowski 1375182 2007-09-21 18:12 xchat-gnome_1:0.18-0ubuntu2.patch

That's the patch between 1:0.18-0ubuntu2 from Ubuntu gutsy and 1:0.17-2, the current xchat-gnome package in unstable. Quite useless, if you ask me. Who really want's to read a 1.4M patch?

Thanks to Alexander Wirt we now have an updated backports.org policy, please take a look at his mail to our mailinglist if you are responsible for one or more backports. The two most important changes are a new version number scheme and the now required inclusion of more changelog entries in the changes file.

My colleague Jonas updated his 3dm2 Debian packages for i386 and amd64 to the latest release 9.4.1.2 today. Unfortunately 3ware decided to use a Java based installer for the latest releases, so it was quite a PITA to update the packages.

I switched my blog from PyBlosxom to Serendipity, and enabled all these shiny new (at least for me and my blog) comment and trackback things. Importing my old blog entries was easy, Serendipity is able to import blog entries from an RSS feed, but unfortunately the categories of older entries have been lost. Thanks to Apaches mod_rewrite the old RSS/Atom feed URLs still work, but I modified my Planet Debian subscription so in the future you'll only see my Debian related blog entries there.

As a result I'm no longer interested in maintaining the Debian package of PyBlosxom, drop me a mail if you want to take over the package.

Today I wondered about a really bad performance when running the create test from sql-bench on a freshly installed 64-bit OpenSuSE 10.2 system (Linux 2.6.18.8-0.3, MySQL 5.0.26-12). Using the same hardware, running this test on Debian 4.0 (Linux 2.6.18-4-amd64, MySQL 5.0.32-7etch1) performed much better.

I'm not sure why, but replacing the OpenSuSE 10.2 default kernel with a self compiled vanilla kernel fixed the problem. No other changes have been made on the system.

Using the OpenSuSE 10.2 default kernel:

alter-table: Total time: 34 wallclock secs ( 0.04 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.05 CPU)
ATIS: Total time: 10 wallclock secs ( 3.08 usr 0.14 sys + 0.00 cusr 0.00 csys = 3.22 CPU)
big-tables: Total time: 8 wallclock secs ( 1.53 usr 0.22 sys + 0.00 cusr 0.00 csys = 1.75 CPU)
connect: Total time: 36 wallclock secs (12.46 usr 5.25 sys + 0.00 cusr 0.00 csys = 17.71 CPU)
create: Total time: 1312 wallclock secs ( 1.17 usr 0.46 sys + 0.00 cusr 0.00 csys = 1.63 CPU)
insert: Total time: 544 wallclock secs (158.79 usr 18.45 sys + 0.00 cusr 0.00 csys = 177.24 CPU)
select: Total time: 177 wallclock secs (15.81 usr 1.29 sys + 0.00 cusr 0.00 csys = 17.10 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time: 3 wallclock secs ( 1.27 usr 0.24 sys + 0.00 cusr 0.00 csys = 1.51 CPU)

Using a self compiled vanilla kernel:

alter-table: Total time: 15 wallclock secs ( 0.01 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
ATIS: Total time: 8 wallclock secs ( 2.76 usr 0.35 sys + 0.00 cusr 0.00 csys = 3.11 CPU)
big-tables: Total time: 7 wallclock secs ( 1.76 usr 0.66 sys + 0.00 cusr 0.00 csys = 2.42 CPU)
connect: Total time: 37 wallclock secs (13.47 usr 6.53 sys + 0.00 cusr 0.00 csys = 20.00 CPU)
create: Total time: 49 wallclock secs ( 1.20 usr 0.45 sys + 0.00 cusr 0.00 csys = 1.65 CPU)
insert: Total time: 527 wallclock secs (149.32 usr 26.16 sys + 0.00 cusr 0.00 csys = 175.48 CPU)
select: Total time: 172 wallclock secs (14.62 usr 2.02 sys + 0.00 cusr 0.00 csys = 16.64 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time: 3 wallclock secs ( 1.25 usr 0.22 sys + 0.00 cusr 0.00 csys = 1.47 CPU)

The results above both come from an Intel Core2Duo with 2.13 GHz and 4 GB of RAM, but the actual problem was completely reproducible on an AMD Athlon 64 with 3.5 GHz and 1 GB of RAM.

Last week the Berkeley DB used by the Jabber server of our local linux user group crashed again. It was the second database crash in six months. But this time even db_recover was unable to repair the database, so I did what I had on my TODO list since the first crash: Migrate to ejabberd, which I was already using on two other Jabber servers. Meanwhile the service and all transports are back up again. There's only one visible change compared with the old setup, for security reasons connecting through port 5222 now requires starttls.

Last week the Berkeley DB used by the Jabber server of our local linux user group crashed again. It was the second database crash in six months. But this time even db_recover was unable to repair the database, so I did what I had on my TODO list since the first crash: Migrate to ejabberd, which I was already using on two other Jabber servers.

Meanwhile the service and all transports are back up again. There's only one visible change compared with the old setup, for security reasons connecting through port 5222 now requires starttls.

Jun 7 13:35:14 magellan gdm[4893]: gdm_slave_xioerror_handler: Schwerwiegender X-Fehler - :0 wird neu gestartet Happened during a demonstration of GNOME 2.18 on my notebook...

Support of the Telepathy backend in Gossip was marked deprecated in 0.25, and completely removed from upstreams Subversion repository after the release of 0.26. I disabled it in the Debian package with yesterdays upload of 0.25-1 to unstable. If you really want to use Telepathy just take a look at Empathy, which is a fork of Gossip using Telepathy as backend.

I was looking for a XMPP/Jabber implementation for Python since a while, but wasn't happy with the available libraries. Yesterday in the evening I stumbled across xmpp4r, a XMPP/Jabber librabry for Ruby, which looked like it has everything I need. And indeed, after a few hours playing around with xmpp4r, I decided to use Ruby for this special project.